Interactive Programs in Dependent Type Theory 


Peter Hancock 1 and Anton Setzer 2 

1 Dept, of Computing Science, University of Edinburgh, James Clerk Maxwell 
Building, King’s Buildings, Mayfield Road, Edinburgh EH9 3JZ, Scotland, 

fax: +44 131 667 7209, phone: +44 131 650 5129, pgh@dcs.ed.ac.uk. 

2 Dept, of Mathematics, Uppsala University, P.O. Box 480, S-751 06 Uppsala, 
Sweden, fax: +46 18 4713201, phone: +46 18 4713284, setzer@math.uu.se. 


Abstract. We propose a representation of interactive systems in depen¬ 
dent type theory. This is meant as a basis for an execution environment 
for dependently typed programs, and for reasoning about their construc¬ 
tion; there may be wider applications. The inspiration is the ‘I/O-monad’ 
of Haskell. The fundamental notion is an I/O-tree; its definition is para- 
meterised over a general notion of dependently typed, command-response 
interactions called a world. I/O-trees represent strategies for one of the 
parties in a command/response interaction - the notion is not confined 
to functional programming. The definitions make essential use of the 
expressive strength of dependent typing. We present I/O-trees in two 
forms that we call ‘non-normalising’ and ‘normalising’. The first form, 
which is simpler, is suitable for Turing-complete functional programming 
languages with general recursion. The second is definable within (ordi¬ 
nary) normalising type theory and we identify programs written in it 
as ‘normalising I/O-programs’. We define new looping constructs (while 
and repeat), and a new refinement construct (redirect), which permits 
the implementation of libraries. We introduce a bisimulation relation be¬ 
tween interactive programs, with respect to which we prove the monad 
laws and defining equations of while. 

Keywords. Functional programming, reactive programming, interac¬ 
tion, dependent types, monadic I/O, repetition constructs, refinement. 

1 I/O Concepts in Type Theory 

Programming languages based on dependent types. A bit over 20 years ago 
Martin-Lof suggested that his type theory, originally developed as a framework 
for constructive mathematics, could be considered as a programming language 
[4]. Since that time, his suggestion has been taken up and explored in a number 
of ways (see for example in [6]). A question which so far seems to have received 
little attention is what form of input-output interface such programs should have. 
Indeed it is only in the last 10 years or so that this question has received a satis¬ 
factory answer in the context of conventional functional programming, through 
the efforts of Moggi [5], Wadler [10], and others. 

Dependent types give us the ability to set up type systems for program¬ 
ming which can express with full precision any property we know how to define 
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mathematically. For example, we can express the requirement for a function 
which maps lists to sorted lists using a dependent type [6]. Remarkably, with 
certain provisos of largely academic interest, we can still check the type of a pro¬ 
gram mechanically, and type-correctness carries full assurance that it satisfies 
its specification. The interest of dependent types for programming is therefore 
considerable. In the past few years, implementations of dependent type systems 
for functional programming have begun to appear [1]. 

Conventions, and plan of paper. In the following, we will work in standard 
dependent type theory (for example [6]) with the usual introduction and elimi¬ 
nation rules and intensional equality, extended by some other rules. We will refer 
to it simply as ‘type theory’. The notation we use, which is for the most part 
standard, is summarised in the appendix of the paper. Note that we sometimes 
omit indices and superscripts. 

The plan of the paper is as follows. In the remainder of this section, we 
draw attention to the need for a model of interaction in type theory, and recall 
the approach taken by the designers of the functional programming language 
Haskell, using a monadic type form whose values are I/O-programs. In the next 
section, we present our extension of this notion, making use of type dependency. 
The third section introduces two repetition constructs (while and repeat), and 
a refinement construction. In the fourth, we point out that these can destroy 
normalisation, and develop an alternative formulation which preserves it. Finally 
there is a concluding section, followed by a summary of our notation. 

The need for interactive programs in type theory. Traditional ‘batch’ programs 
may be written in type theory as functions from input values (given in advance) 
to output values. The output from such a program is obtained by evaluating the 
result of applying the function to its input. This batch model is adequate for a 
large class of programs, typically computationally intensive numerical search or 
optimisation programs. It is not however adequate for a program which runs, 
say, in the guidance system of an airplane. 

The programs with which one is ordinarily confronted participate in inter¬ 
actions with their environment, i.e. us, while they are running. We give input 
via various devices like keyboard, mouse, or microphone and get output via 
devices like monitor, printer or loudspeaker, and this input-output cycle is re¬ 
peated again and again. There may also be interaction with the file system and 
the network. Other kinds of program may be embedded in a physical system, in 
which there is continual interaction with physical sensors and actuators of some 
kind. So if we want to use type theory as a practical functional programming 
language, we have to consider how to use it to write interactive (or reactive) 
programs. 

Some approaches to interactive programs in type theory. In conventional func¬ 
tional programming, several approaches to interaction have been pursued. A 
good survey of some of these approaches is made in [7]: dialogues (or lazy 
streams), continuations, and monadic I/O. (Mention should also be made of 
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the ‘uniqueness types’ of the language Concurrent Clean, although a definitive 
exposition of this approach doesn’t seem to have been published yet. 1 In this 
paper we follow the monadic approach, introduced by E. Moggi [5], upon which 
the input/output (I/O-) system of the language Haskell 2 has been erected. A 
monad (the concept comes from category theory) is a triple (M,*,r?), whose 
components, written in dependent type theory, have types 

M : Set —> Set , 

*: (A,B :Set,p:MA,q: A^MB) ^MB , 

7]: {A: Set, a: A) ^MA , 

such that the following laws hold with respect to suitable equality = (which will 
not be definitional equality). 

Va *a,b q = qa , 

P*A,B ^X.Tix = P , 

(P *A,B q) *b,c r = p *A,B (A x.q x * B ,c r) . 

A special case of a monad is the I/O-monad. When referring to the I/O-monad 
we write (10 A) instead of (MA). The interpretation of 10 is as follows. 

(a) For a given set A, (10 A) is the set of interactive programs which may or 
may not terminate, but terminate only with a result a of type A. 

(b) p* q is a program whose execution begins by executing p. If execution ter¬ 
minates with result a, then the program continues with (qa). The result of 
the whole program is the result of (qa). 

(c) rja is the program which has no interaction but terminates immediately, 
yielding result a. 

In addition to these general components of any monad, there are functions spe¬ 
cific to the kind of computations the programs are to evoke. For example, we 
can deal with programs that communicate by writing and reading strings (such 
as text lines): write : String —> 10 1, read : 10String. Here (writes) is the pro¬ 
gram which outputs s on some device and returns •, and read : 10 String, is the 
program which reads a string and returns it. 

Note that type checking does not require any interaction. What we really 
type check is the text of the program, rather than its execution. To execute or 
run a program means to interpret the program text as the specification of a 
certain I/O-behaviour. 

For the I/O-monad, one sees that the laws mentioned above should hold with 
respect to an equality which identifies behaviourally equal programs. 

Interactive programs are written in Haskell by using a form of the I/O-monad 
that gives access to most of the usual facilities of a traditional operating sys¬ 
tem, including files, graphics, time, as well as control features such as exception 
handling or multi-threading. 

1 http://www.cs.kun.nl/~clean 

2 http://haskell.org 
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The I/O-monad seems to be the most promising approach for the represen¬ 
tation of interactive programs within dependent type theory. To add it to type 
theory as a new concept with new typing rules would however require extending 
a considerable body of metatheoretical research to the extended theory. Since 
we can define in type theory powerful data types, an easier approach is to define 
the I/O-monad directly in type theory. Thus the only feature we need over and 
above ‘mathematical’ type theory is that of actually running an I/O-program. 

2 I/O-Trees 

Worlds. Interactive programs are built from interactive commands. In dependent 
type theory we can define such a set of interactive commands in a very general 
way: 

General assumption and definition 2.1. A world w is a pair (C,R } such 
that C : Set and R : C —> Set. In the following w is always a world (C,R ). We 
will in most cases omit the parameter w. 

The idea is that C is the set of instructions or commands. These include com¬ 
mands to obtain input, commands to obtain output, and commands with a mixed 
effect. If c : C is a command, then (R, c) is the type of responses or termination 
codes produced when such the command c has been performed. So we might 
have constructors 

(a) write : String — »■ C with U(writes) = 1 , and (writes) is the command to 
write s and return • : 1 for success. 

(b) read : C, with (R .read = String), where read stands for the command to 
read a string and returns it. 

Of course in practice the commands would be more complex. For example, 
there might be an embellishment of write where i?(writes) = {success, fail} and 
(write r) returns the information whether the output was performed successfully 
or not. More generally, there may be commands expressing interaction with file 
systems, network etc. 

I/O-trees. We want to define the I/O-monad as a data type already in type 
theory. It seems particularly suitable to define it as an inductive data type, 
because using the elimination rule associated with such types we can then carry 
out program transformations. A naive approach would be to take *, rj and the 
additional primitive instructions such as read and (write a) as constructors for 
this type. However we need to verify the monad laws, and it turns out to that 
the naive approach requires us to define a rather complicated equality relation. 
The situation is analogous to the definition of the set of natural numbers. We 
could define it from 0, 1 and +, which correspond in the I/O-monad to rj, the 
primitive instructions and *. It is however much better to take 0 and successor S 
as constructors, and to define 1 and addition. What corresponds now to S in the 
IO-monad? This should be the operation which takes an instruction and a family 
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of programs depending on the result of performing that instruction, and creates 
a new program that begins by performing this instruction and then continues 
with the program determined by its result. Instructions are given by C, where 
w = (C , R) is a world, and R provides the result type.The rules for IO u; A are: 
IO„, : Set —> Set, where IO„, A has constructors 
leaf : A —> IO„, A , 
do : (c : C, p : I? c —> 10 A) —► 10 A . 

The constructor (leaf a) is what was written r/ r f before, and (do c p) denotes the 
program that first executes the command c, and depending on the result r : Rc 
of this execution continues with ( pr ). 

Note that (10A) is now parametrised with respect to w, a feature which 
can be expressed only with dependent types. 

(I0 W A) is the set of well-founded trees with leaves in A and inner nodes 
labelled by some c : C having branching degree (Rc). If we compare (10A) 
with standard type theory we see that we simply have a slight extension of the 
W-type. In fact we can even define (10 A) directly in terms of the W-type: 

IO w A= W x:(C + A).R'x , 

where /i"(inl c) = Rc , 

R'(inra) = 0 . 

We therefore call (10 w A) the type of I/O-trees with leaves in A. 

Execution of I/O-programs. Up to now we have defined an inductive data type 
of I/O-programs within constructive type theory, but there is still no way to 
actually run such a program. Execution is an external operation rather than 
a constant within type theory. Just as an implementation of type theory will 
provide an external operation or facility to compute (and display) the (head-) 
normal form of a term, so we propose to provide a second operation which 
executes a term which denotes an I/O-program. 

More precisely, this works as follows. Let wo = (Co,Ro) be a world corre¬ 
sponding to the real commands, so that to every c : Co there corresponds a 
real I/O-command c having some value r : R.q c as result. If we have derived 
p : IO„, 0 A then the external operation execute can be performed upon p. The 
operation execute does the following. It reduces p to canonical form, i.e. to a 
term of constructor form. This form must be either (leaf a) or (doeg). If it is 
(leaf a), then a : A and execution terminates, yielding as result a (which, when 
running the program from a command line will be displayed in a similar way 
as the result of the evaluation of an expression). If it is (doeg), then first the 
interactive command corresponding to c is performed obtaining a result r : Rc, 
after which execution continues with (gr). 

Roughly speaking a program p is evaluated to normal form, as it were ‘fetch¬ 
ing’ the next instruction. The instruction is ‘executed’, and the result used to 
select the next program to be evaluated. Another way of looking at it is that 
through successive interactions we trace out a descending chain through the tree 
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A first example. In the following example we assume commands readstr for 
reading a string, (writestr s) for writing a string s. Further let =string be a 
decidable (boolean valued) equality on strings. The following program prompts 
for the root-password. If the user types in the right one (“Wurzel” 3 ) the program 
terminates successfully, but otherwise responds with “Login incorrect” and then 
fails. We use some syntactic sugar. 

C = { readstr } U { writestr s \ s : string } : Set , 

R : Set , 

R readstr = string , 

R (writestr s) = 1 , 

Wurzel = do writestr “Password (root):” 

Xa. do readstr 

As. if s = “Wurzel” 
then leaf success 

else do (writestr “Login incorrect”) 

Xa. leaf fail 

: 10 { success, fail} . 

r], *, interact. It is now easy to define the operations tj and *: 

rja = leaf a , 
leaf a *a,b q = qa , 
docp*A,B q = doc(Xx.px *a,b q) ■ 

The monad laws are then provable for well-founded trees with respect to exten- 
sional equality. 

Additionally we can define a function interact : (c : C) —> 10 (Re) by 
interactc = doc(Az.leaf x). The program (interactc) simply executes the com¬ 
mand c and returns its result. 


3 Constructions for Defining I/O-trees 

It should be possible to define interactive programs with infinitely many inter¬ 
actions. For instance, if we execute an editor and never terminate the program, 
the execution should go on for ever. So we need constructions for defining such 
programs. This will however destroy normalisation. We will see in Sect. 4, how to 
modify the concept in order to obtain a normalising type theory. The definitions 
of all constructions in this section are possible only in the presence of dependent 
types, which demonstrate their expressive power. 

We will first look at the repeat-loop, which is very useful in examples. 


This really happened. 
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repeat. Assume A, B : Set, b : B, p : B —> 10™ (B + A). We want to define 
a program repeat A Bbp : 10 w A, which, when executed, operates as follows. 
First program ( pb ) is executed. If it terminates with result (ini b'), then the 
program continues with (repeat A Bb' p). If it terminates with (inr a), the program 
terminates and returns a. 

However, if pb = leaf a for some b : B, this might result in an expression that 
does not evaluate to constructor form - for instance (repeat B hAx.leaf (ini 6)). 
Therefore we have to restrict p, and the easiest solution is to replace (10 (B + 
A)) by (10+ (B + A)). Here for D : Set let 10+ D = Sc-.C.Rc^ 10™ D be the 
set of I/O-programs with results in D, with one interaction (namely command 
c). Let do+ cp = (c,p ) : 10™ D and, if p : 10+ D, let p~ : 10 w D be defined by 
(do+ cp)~ = docp. 

The definition (which uses full recursion and so allows us to define non-well- 
founded trees and form non-normalising terms) of the repeat construction is as 
follows: 


repeat™ : (A, B : Set, b : B,p : B —> 10+ (B + A)) —> 10,,, B , 
repeat w A Bbp = (pb)~ * w ,b+a,a q , 

where q (ini b') = repeat^ A B b'p , 
q (inr a) = leaf a . 

Example. As an example we define a rudimentary editor. The only command 
is readchar, which has as result either a character c typed in, cursorleft for the 
cursor-left-button or terminate for some key associated with termination. The 
program reads the text created by these keys and returns the result, ((truncate s) 
will be the result of deleting from string s the last letter, (append sc) an op¬ 
eration which appends at the end of string s character c and the empty 
string.) 


C = {readchar} : Set , 

R : Set , 

Rc= {chc | c : char} U {cursorleft, terminate} . 
editor = repeat^ C R \ string string As.do+ readchar q , 
where q (chc) = leaf (ini (append sc)) , 

q cursorleft = leaf (ini (truncate s)) , 
q terminate = leaf (inr s) . 

While-loop. While loops are defined similarly to repeat loops. 

while™ : (A, B : Set, b:B,p:B -► (10+ B + 10™ A)) ■—* 10™ A . 

The definition proceeds by cases on the value of (pb). If it is of the form (ini q), 
then q is executed, and, once it terminates with result b', the program continues 
with (while™,,* B b' p). If it is (inr q), q is executed and its result returned as final 
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result. The definition, which uses again full recursion, is 
while^A Bbp = f (pb) , 

where f (inlq) = q~ * w ,b,a A6 / .while Wi A B b' p , 

/ (inr q) = q ■ 

It is now an easy exercise to express while by repeat and vice versa. 

Redirect. * can be regarded as “horizontal composition” of programs. There is 
also a “vertical composition”: 

Assume worlds w = (C , R) and w' = (C 1 , /?/), A : Set and p : IO u . A. We want to 
refine p to a program in world «/, by replacing every command c : C by a program 
(q c) in world w' which has as result an answer r : Rc. This suggest q to have type 
(c : C) —+ 10,,,' f J? c). However, if we allow (q c) to be a leaf and p has infinitely 
many commands, this will allow us to construct an expression that cannot be 
evaluated to constructor form. To avoid this we assume q : (c : C) —> 10+, (Rc). 
The construction that results is 

redirect^/ : {A : Set,p : IOu, A,q : (c : C) 10+ (Rc)) -* IOu,' A , 
where redirect^,^'^ (leaf a) q = leaf a , 

redirect™,™'^ (docp) q = ( qc)~ * w ',r c ,a Ar.redirect^,^/^ ( pr ) q . 

Example. Let the high level world be wq = (Co,Ro), with Co = {read} U 
{writes | s : string}, read should be a command for reading a string, so 
Bo read = string, and (writes) should be an instruction for writing a string, 
Ro (writes) = 1. Let the low level world vj-\ have commands for reading a key, 
writing a symbol, and movements of the cursor left and right. Let q: (c : Co) —> 
10 Wl (Ro c), where ((/read) is some editor, which uses the keys to define a string 
and has as result that string, and (q (write s)) be some output routine for strings, 
(redirect p(/) generates a program using basic commands from a program p using 
the high level commands . 

This illustrates that with redirect we have the possibility of building up li¬ 
braries. In other words, we can define worlds with very complex and powerful 
I/O-commands and write in the same language programs for transforming these 
high level programs into those using very basic commands. 

Equality. With while— and repeat—loops we introduce non-well-founded 1/0- 
trees. Even with extensional equality it seems that it is no longer possible to 
prove the monad laws. So extensional equality seems to be too weak for dealing 
with non-well-founded programs. Instead we use bisimulation as equality. In 
[3] I. Lindstrom has given a very elegant definition of such an equality. This 
equality, transferred to our setting, is defined as Vn.p ~' w An q, where p ~' w A n ( I 
expresses that p and q coincide up to height n. In the following the world w will 
be a parameter in all definitions, which we omit for simplicity. We will refer to 
the equality-types =c and =a on C and A and only identify commands and 
leaves, which are equal with respect to these equalities. So we do not make use 
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of any user-defined (setoid-)equality on C, A. In a followup to this article, we 
will consider the generalisation to user-defined equalities. 

~ : {A : Set,p, q : 10 A) —> Set , 
p' : (A : Set, n : N, p, q : 10 A) —> Set , 

(p —a q) = Vn : N.p ~’ An q, 

(P -.4,0 q) = T u 

(leafa — A ,n+i do cp) = (do cp —amA ’.l leaf a ) —- 1 - , 

(leaf a ~' A n+1 leaf a ') = (a =a a') , 

(do cp —A,n+i doc'p') = 3 p: (c =c c').Vr : Rc.pr — A n p’ (Jc Rcc'pr) . 

Definition 3.1. (a) Let case-distinction for 10 be the rule (under the assump¬ 
tions that A : Set, B : (p : 10 A) —> Set,): 

C“ B : ((a : A) —> B (leaf a), (c : C,q : Rc ^ lO A) ^ B (docq), 
p : 10 A) —> Bp . 

(b) Let TT(IO) be the extension of the standard type theory used in this article 
by the defining rules for 10 and case-distinction for 10. 

Lemma 3.2. TT(IO) proves the following (under the assumptions that A,B : 
Set, and all other variables are of appropriate type) 

(a) is reflexive, symmetric and transitive. 

(b) p~ A p' -> (Vo : A.q a~ B q' a) -> p * a ,b q p' *a,b q' ■ 

Proof (a): First we prove the lemma with replaced by — An by induction 
on n : N, using the elimination rules for equality. Then the assertion follows by 
the definition of ~. (b) Show that p — An p' and Va : A.q a — Bm q' a imply 
do pq ~ B min | r| TO j do p' q' by induction on n. □ 

Theorem 3.3. TT(IO) proves the monad laws with respect to ~a- 

Proof. The first law holds definitionally and a fortiori with respect to by 
its reflexivity. The second and third laws are proved first with ee A replaced by 
—' A n using induction on n and case distinction on p. Then the assertion follow 
from the definition of □ 

I/O-trees as a general concept for command/response-interaction. It seems that 
the applications of I/O-trees, which are in general non-well-founded trees, are not 
limited only to functional programming languages. I/O-trees cover in a general 
way command/response-interaction with one agent (a program) having control 
over the commands. Every I/O-behaviour corresponds, up to the equality we 
have introduced above, to exactly one I/O-tree. Therefore I/O-trees are suitable 
models for this kind of interaction. 
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4 Normalising Version 

Counterexample to normalization. If we take standard reduction rules corre¬ 
sponding to the equalities given above, the above definitions give non-norma¬ 
lizing programs. Let for instance A = B = C = N, let ( Rc ) be arbitrary, and let 
w = (C , R), f : N —> N. We omit the parameter w. 

p := An.do + (f n) Ax.leaf (ini (n + 1)) : N —> IO + {A + B) , 
repeat Op —» do (/ 0) Aa:. repeat (S0)p 

—» do (/ 0) Aa;.do (/ (S 0)) Ay.repeat (S (S 0)) p 
—> do (/ 0) Ax.do (/ (S 0)) Ay.do (/ (S (S 0))) A^.repeat (S (S (S 0))) p 


We see that definitional equality is no longer decidable, since we cannot de¬ 
cide whether two functions N —* N are extensionally equal. This implies the 
undecidability of type checking, since with an type checking algorithm we can 
decide definitional equality (for a, b : A, the term XB. f.f a is of type (B : 
(x : A) —> Set, / : (x : A) —> B x) —> B b if and only if a and b are definitionally 
equal). In the following we are going to develop a normalizing variant of the 
above. 

How to regain normalisation. The main idea is to introduce either repeat or 
while as a constructor, where with while, the definition of * and the proofs of 
equalities turn out to be easier. One problem is however that while (the same 
is the case with repeat) defines an element of (IO w A) by referring to (IO,„ B) 
for an arbitrary set B. To demand that (IO,„ A) is a set means to define a set 
by referring negatively to all sets, which is a problematic definition. (The typing 
rules require that if A is a set, (IO„, A) is a type). 

In order to control this we will restrict the sets referred to in while to elements 
of a universe, which we extend in order to get representatives for 1 + R c. 
General assumption and definition 4.1. (a) Let w = (C,R ) be a world. 

(b) Let U : Set, T : U —> Set be some fixed collection of sets (i.e. a universe). 

(c) Let set := U + C, el : set —» Set, el (ini u) = Tu, el(inrc) = 1 + Rc, R 
according to the world w. We write (1 + Rc) for (inrc). 

All the following definitions depend on w, U, and T as parameters, which we 
however omit for simplicity. 

We can now omit the constructor do, since it can be simulated by while. 
Definition of IO A. 

IO : Set —* Set , where (IO A) has constructors 
leaf : A -> IO A , 

while : (u : set, a : elu, n : elu —> (IO + (elu) +IO A)) —> IO A , 
and IO + : Set —> Set , 

IO + A = Ec: C.R c —*40 A . 
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Monad operations. Now we can define the Monad operations (where sets have 
to be replaced by elements of the universe) 

"Ha := l ea f a > 
leaf a *a,b q = qa , 

whil euap*A,Bq = whilet ia(p® ABu q) , 

where© : (A, B : Set, u : set,p : elu —> (IO + (eltt) + 10 A), 
q: A^IOB) ^elw^ (IO + (elu) + IOB) , 
if pb = blip', then ( P® A ,B, u q ) & = ini p' , 
if pb = imp', then ( P® A ,B, u q ) & = inr (p' *a,b q) ■ 

Do. We define now the operation (do,4 cp) (note that do is not a constructor): 

do,4 cp = while (1 + Rc) (ini*) q , 
where q (ini •) = ini (c, Ar.leaf (inr r )) , 
q (inr r) = inr (pr) . 

Split. Elements of (10 A) can be regarded as representatives of non-wellfounded 
trees. We define a function splits, which determines whether a value p : 1(3 A 
is a leaf labelled by a : A (then split A p = inr a) or represents a program which 
executes command c and depending on the result r : Rc of it executes program 
qr (then splits p = ini (c, q)). In the latter case p represents a tree with root 
labelled by c and rth subtree being the tree represented by (qr). 

split : (A:Set,p:IOA)->(IO+A + A) , 
splits (leaf a) = inr a , 

If pa = inr <7, then splits (while uap) = splits q , 

If pa = ini (c, q), then 

splits (whilewap) = ini (c, Xr.qr Ax.while uxp) . 

Execution of I/O-programs. Assume a fixed world u>o = (Co,Ro) corresponding 
to real commands, as before, execute, adapted to the new setting, operates as 
follows: Applied to a program p : IOc a ,R a A it evaluates split 4 p. If the result is 
(inr a), then execute stops with result a. If splits p = ini (c, q), then c is executed, 
and depending on the result r, execute continues with (qr). 

Normalising I/O-programs. When using only inductive data types with their 
elimination rules, the type theory in question is strongly normalising. Therefore, 
when running execute, at the beginning and after the result of a command 
is obtained, splits applied to the respective program will always reduce to an 
element of the form (inr a) or (inl(c, q)). However, it might be that infinitely 
many commands are executed, which is to say that the tree is not necessarily 
well-founded. We call a program which at the beginning and after the result 
of a command is obtained, executes the next command after finite amount of 
time, or terminates, a normalising 1/O-program. (10 A) (together with execute) 
represents a class of normalising I/O-programs. 
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Equality. Under the same assumptions as in Sect. 3 we can define now an equal¬ 
ity on elements of 10 A. However, we use split in order to get access to the 
corresponding tree-structure: 

~ : (A : Set,p, q : 10 A) —* Set , 

: {A : Set, n : N,p, g : 10 A) —> Set , 

(p ~A q) = Vn : N .p ~' A>n q , 

P -4.0 9 = T • 

P -A,n+1 Q = (splits p splits q) , where 

: (A : Set, n :N,p,q : I0 + A + A) —>■ Set , 

(inra ~" An inl(c,p)) = (inl(c,p) —'X n inra) =_L , 

(ini (c, q) n ini (cf,q')) =3p : (c =c c').Vr : Rc.qr q' (J CRcc'pr) . 

Note that n identifies programs which behave identically in the first n steps, 
and therefore identifies exactly behaviourally equal programs. Note however 
that we only identify commands c : C, which are equal with respect to =c- 

Proof of the monad laws, definitional equalities for while and other standard 
properties. The following can be proved inside type theory. (Some indices or 
superscripts have been left implicit). 

Lemma 4.2. (a) r) a *p ~ A p a. 

(b) ~,4 and ~ A n are reflexive, symmetric and transitive. 

(c) If pa =io(eiu)+i 0 4 inr 9> then whileuop q. 

Proof, (a) is trivial, (b) follows with replaced by ~' A n by induction on n - 
in case of symmetry and transitivity one uses additionally the elimination rules 
for =c- From this the assertion follows. 

(c) split (while uap) = 10 + 4+4 split q. □ 

For stating and proving the next lemmata we introduce an equality on the type 
of p in (whileuap), i.e. (elw) —► (I0 + (elw) + A): 

Definition 4.3. 

~ w : {A : Set, u : set, 

p, q : (elu) -► (10+ (elu) + 10 A)) -*■ Set , 
p q = Vx : el u.px i^ ux qx , where 
— w,aux : (A : Set, u : set, p, q : I0 + (el u) + 10 A) 

—* Set , 

(ini q ~^ ux inrg) = (inrg ~^ ux inlg) = T , 

(inr q ~^ ux inr q) = (q q') , 

(ini (c, q) ini (c', q')) = 3p: (c =c c').Vr : Rc. 

qr ~ e iu q' (J CRcc'pr) . 
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Similarly we define ~ w/ , ~ w > aux/ with an additional argument n : N and refer to 

—A,n’ —el u,n dsfecid °f —At -elu- 

Lemma 4.4. (a) (p 0 Pi A Va : A.q 0 a qi a) -> (p 0 * <Zo -b Pi * Qi)- 

(b) po u Pi whileuapo —a whileuapi. 

(c) For p : 10 A, q : A —> 10 B, r : B —> 10 D it follows 
(p*q)*r~ D p* Ax.((g x)*r). 

Proof. We prove (a) - (c), with Ax. ~ x . Ax. — xu replaced by Ax. — Xtn , 

Ax. —™ u n , simultaneously by induction on n. The case n = 0 is trivial, so we 
assume the assertion has been proved for n and prove it for n + 1: 

(a) Side-induction on po, side-side-induction on p-\: 

If po = leaf ao and pi = leaf ai, then ao =a ai and go f*o — B n+ i qi «i ■ 

If po = while uapo with poa = inrpo, then po —a Po, and by 
Po * go = while tt a (po@go), (Po@5o) a = inr (p 0 * g 0 ) it follows 
Po * go — b Po * go 5 and the assertion follows by side-IH for po instead of po- 
Similarly the assertion follows if pi is of a similar form. 

Otherwise p* = whileu* Olpi, with pg a* = ini (cj,pj), 
split pi = ini {a, Xr.pi r * Ax.while u, xpg). 

By pi —A,n+1 Pi there exists p CoC 1 : (co =c Ci), and for 
ro '■ Rep, r\ := i CRcq c\p CoCl r o there exist proofs of 
Po ro * Ax.while no xpo — A n Pi ri * Ax.while u\ xpi. 
split (pi * qi) = ini (a, Xr.p t r * Ax.whileu, x (p;@g;)) 

= ini (a, Xr.pi r * Ax.whileu* xp) * g*}. 

We have to show that for ro, ri as above 

Po ro * Ax.while uo xpo * go — Pi r\ * Ax.while u\ xpi * gi. 

BylH (c) and symmetry p"jrj*Ax.whileUjXpj*gj — Bn (p,r,*Ax.whileUjxpj)*g,, 
and by IH (a) (pbro * Ax.whileuo xpo) * go —B n (Pi r t * Ax.whileui xpi) * qi. 
The assertion follows now by transitivity and symmetry. 

(b) If pi ai = inr gj, then whilett aiPi = qi, go — A n+1 gi. 

Otherwise Pi ai = inl(cj,gj), split (while ttOjPj) = ini (c,,Ar.gjr* Ax. while uxpi). 
By assumption there exists p Co , c 1 as in (a) and for ro and ri as in (a) proofs of 
go ro gi r\, and furthermore by IH (b) proofs of whileuxpo n 
whileuxpi for x : el(u). The assertion follows by IH (a). 

(c) is proved by side-induction on p. If p = leaf a this follows by reflexivity. 
Otherwise p = while uap, (p* q) *r = while ua ((p@g)@r), p * Ax.gx * r = 
whileua(p©Ax.gx©r), by side-IH (p@g)@r~ w/ r , ) „„ +1 p@Ax.gx©r, 

and by (b) for n + 1, as just proved, the assertion follows. □ 

Lemma 4.5. (a) p* Xx.r] x ~ A p. 

(b) split (do cp) =io+ a+a id (c,p'} for some p' s.t. Vr : Rc.pr p' r. 

(c) If P a = IO + (ei«)+io a id (c, g) then 
while uap ~ A docAr.gr * Ax.whileuxp. 

Proof, (a) follows by straightforward induction on p and Lemma 4.4 (b). 

(b) split (docp) = (c, Ar.(leaf (inrr)) * Ax.while (1 + Rc) xq) 

= (c, Ar.while (1 + Rc) (inrr) g), 
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where q is as in the definition of (do cp). For r : Rc we have by Lemma 4.2 (c) 
while (1 + Rc) (inrr) q ~a pr. 

(c) follows by (b) and split (whilenap) = ini(c, \r.q(r) * Ax.while uxp). 

□ 


5 Conclusion 

We have identified a need for a general and workable way of representing and 
reasoning about interactive programs in dependent type theory. We introduced 
in dependent type theory the notion of an I/O-tree, parameterised over a world, 
making essential use of type dependency. We gave it in two forms. The first 
breaks normalisation, but is conceptually simpler and suitable if one is tol¬ 
erant of a programming language with ‘bottom’, or divergent programs. The 
second preserves normalisation. We called programs of this kind “normalising 
I/O-programs”. We introduced an equality relation identifying behaviourally in¬ 
distinguishable programs and showed that the monad laws hold, modulo this 
equality. (For the normalising version these are Lemma 4.2 (a), 4.5 (a) and 4.4 
(c)). We introduced while-loops in both versions and repeat-loops and redirect 
in the first version (and leave it as an interesting exercise to extend the last two 
constructions to the normalising version). In the non-normalising version the 
characteristic equations for while and repeat are fulfilled by definition, whereas 
in the normalising version we have shown them for while (Lemma 4.2 (c) and 4.5 
(c)). We have characterised do as well in the latter version (Lemma 4.5 (b)). 

In a future paper we will show how to move from one universe to another in 
the normalising version, and will explore the case in which C is a setoid given 
with a specific equivalence relation. In addition we will introduce state-dependent 
I/O-programs, in which the set of commands available depends on the current 
state of knowledge about the world. 


Appendix: notations 

In the paper we do not distinguish between E and IT-type on the logical frame¬ 
work level and as set-constructions. The empty set is denoted by 0, the set 
containing one element by 1 (with element •). The set of natural numbers is 
denoted by N. The injections for the disjoint union A + B of sets A and B are 
written ini : A —? (A + B), inr : B —> (A + B). The elements of Ex : A.B are 
denoted by (a, b). The dependent function type (sometimes written as IIx : A.B ) 
is denoted by by (x : A) —> B, with abbreviations like (x : A, y : B) —> C for 
(x : A) —> (y : B) —> C, (x : A,B) —> C for (x : A, y : B) —> C with y new, and 
(x,y : A) —> B for (x : A,y : A) —> B. We use juxtaposition (/ a) for applica¬ 
tion, having a higher precedence than all other operators, so that for example 
f a = gb means (fa) = ( gb ). The scope of variable-binding operators Ax., Vx., 
3x., Ex. is maximal (so Ax./a b stands for Ax.((/a) =a b)). Some functions 
are represented as infix operators, writing some of the first few arguments as 
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indices. (For instance we write p*a,b Q for ( *ABpq ).) Arguments which are 
written as indices are often omitted. We will omit the type in equality judge¬ 
ments, writing r = s instead of r = s : A. An equation sign = without indices 
denotes definitional equality, whereas we write r =a s (never omitting the A) for 
equality types (which are actually sets). The intensional equality has elimination 
rule J : (A : Set ,B : A — * Set,a,a' : A,p : (a =a a'),Ba ) —> Bo! . Note that 
with extensional equality J could trivially be defined as A A, B, a, a',p, b. b. 
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